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Leveraging  Your  Process  Definition  Investment  to  Support  the 
Planning,  Acquisition  and  Performance  of  Software  Projects 

by 

William  H.  Ett,  Loral  Federal  Systems,  STARS  Program 
Jim  Terrel,  Cedar  Creek  Process  Engineering,  STARS  Program 
Wayne  Sherer,  TACOM  LCSEC  Chief  Scientist 


Introduction 

The  Software  Technology  for  Adaptable,  Reliable  Systems  (STARS)  program  was 
instituted  to  develop  technology  to  support  the  "megaprogramming"  of  software  systems, 
or  systems  in  which  software  is  a  part.  Developing  software  using  the  "mega¬ 
programming"  approach  involves  following  a  defined  process  to  develop  software,  using 
the  concepts  of  architecture-based  and  component  reuse.  The  STARS  program  is 
currently  in  its  technology  demonstration  phase,  where  the  three  STARS  prime 
contractors  are  each  paired  with  a  mihtary  service  team  to  use  STARS 
"megaprogramming"  concepts  to  develop  and  field  a  software  system. 

Experiences  by  aU  three  STARS  contractors,  as  well  as  experiences  on  aU  three  STARS 
demonstration  projects,  have  shown  that  defining  enactable  (or  executable)  processes  is  a 
time-consuming  activity.  Further,  organizations  are  not  taking  fliU  advantage  of  this 
investment  from  the  standpoints  of  project  and  product-quality  planning.  Process 
maturity  assessment  and  process  definition  activities  are  far  too  often  separated  from 
project  management,  when,  in  reality,  their  results  should  be  an  integral  part  of  project 
planning  and  project  management  activities.  Processes  define  activities  that  describe 
work  tasks,  as  well  as  verification,  vahdation,  and  assessment  tasks  that  examine  a 
project's  performance  against  its  compliance  with  defined  product  quality  characteristics. 
Processes  also  define  activities  that  specify  the  entry  criteria  for  initiating  a  process,  as 
well  as  completion  criteria  for  leaving  a  process.  Those  same  activities  should  be 
miiTored  in  our  project  plans  to  ensure  that  quahty  is  built  into  our  planning  process, 
where  activities  can  also  be  used  as  the  basis  for  estimating  schedule  and  resource 
requirements. 

The  purpose  of  this  paper  is  to  describe  how  process  definitions  can  be  leveraged  to 
support  software  project  and  software  sj^tem  acquisition  planning,  project  management, 
and  project  performance.  We  shall  provide  examples  of  how  a  state-of-the-art  process 
management  system,  such  as  the  STARS-sponsored  PEAKS*,  can  support  the  definition 
of  processes  that  can  be  leveraged  to  support  the  above  mentioned  activities. 

This  paper  will  be  organized  into  three  sections; 

•  Section  1  will  describe  characteristics  that  a  "leveragable"  process  definition  should 

possess. 


'PEAKS  (Process  Engineering  and  Analysis  Kernel  System)  is  a  product  of  Cedar  Creek  Process 
Engineering  of  Austin,  Texas.  Cedar  Creek  Process  Engineering  is  a  member  of  the  Loral  STARS  team. 


02/22/95  at  01:26  AM 


Sofrivare  Technology  Conference  '95  Paper 


Page  1 


Section  2  will  describe  how  the  defined  process  for  a  project  may  be  leveraged  to 
support  project  planning  and  performance  activities. 

Section  3  will  present  conclusions  and  describe  our  future  plans. 


Section  1  -  Characteristics  of  the  Leveragable  Process  Definition 

Process  definitions  identify  the  work  that  must  be  performed  to  produce  a  specific  set  of 
work  results,  as  well  as  how  those  work  products  will  be  verified  and  validated.  Process 
definitions  also  identify  the  criteria  required  to  initiate  a  process  and  those  criteria 
required  to  complete  it.  When  committed  to  paper,  the  process  definition  becomes  part  of 
the  organization's  knowledge  base  on  how  business  activities  addressed  by  the  process 
should  be  performed.  Once  a  process  is  defined  and  used  by  the  practitioners  within  an 
organi2ation,  results  from  its  use  can  be  analyzed  and  it  can  be  systematically  improved. 

One  of  the  most  critical  aspects  of  defining  processes  is  determining  if  we  have  defined  a 
"good”  process,  with  respect  to  existing  process  assurance  standards,  such  as  the  SEPs 
CMM  and  ISO-9001,  and  if  the  results  from  performing  the  process  meet  its  stated 
quahty  objectives  for  product  and  service  quahty.  Figure  1  illustrates  an  abstract  process 
definition,  based  on  the  (E)ntry,  (T)ask,  (V)erification  and  Vahdation,  E(X)it  model.  As 
shown  in  Figure  1,  the  process  accepts  required  inputs  and  initiates  its  work  steps  after  its 
entry  criteria  have  been  satisfied.  The  work  steps  of  the  process  are  illustrated  by  the 
"Tasks"  block  and  the  "Verify  and  Validate"  block.  After  the  work  products  and  results 
to  be  produced  by  the  process  are  completed,  the  process  may  terminate  if  its  exit  criteria 
have  been  satisfied.  Note  that  the  "Perform  Tasks"  block  describes  the  woric  that  must  be 
performed  to  achieve  the  results  of  the  process.  It  is  not  the  role  of  a  process  definition  to 
define  how  work  tasks  are  to  be  accomplished.  Also  note  that  the  "Verify  and  Vahdate 
Work  Results"  block  describes  how  work  results  wdl  be  verified  and  vahdated. 

Figure  1  also  illustrates  a  few  other  key  points.  Processes  may  be  instrumented  to  log 
selected  events  for  historical  analysis  and  personal  process  improvement,  to  report  status 
and  events  to  management  and  team  members,  and  to  collect  measurements  on  both 
process  performance  and  product  quality.  Recording  how  much  effort  a  process  requires, 
as  well  as  how  much  calendar  time  it  requires,  is  useful  for  supporting  both  activity 
scheduling  and  effort  estimation.  To  ensure  that  the  process  we  define  meets  established 
government  and  commercial  standards,  we  can  assess  our  process  against  process 
assurance  criteria,  such  as  the  SEI's  CMM  and  lSO-9001.  Once  this  assessment  is 
performed,  pointers  from  the  woih  and  verification/vahdation  tasks  should  be  established 
for  those  process  assurance  criteria  to  support  process  assurance  audits.  Further,  where 
quahty  criteria  have  been  established  for  selected  process  work  products,  pointers  to 
appropriate  product  assessment  criteria  and  checklists  should  be  recorded  and  maintained. 
FinaUy,  we  must  remember  that  the  process  was  defined  for  a  purpose,  and  the  most  vital 
aspect  of  process  assurance  is  to  ensure  that  the  process  that  was  defined,  satisfies  the 
requirements  it  was  intended  to  address;  thus  pointers  to  the  requirements  for  a  process 
should  also  be  maintained.  The  navigation  block  shown  in  Figure  1  describes  the  rules 
for  addressing  problems  foimd  while  performing  verification  and  validation  tasks.  Those 
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rules  identify  where  to  branch  in  the  activity  network  to  address  the  rework  requirements 
caused  by  not  satisfying  specified  verification  and  vahdation  criteria. 


Figure  1:  The  (E)ntry  (T)ask  (V)erification  and  Validation  E(X)it 
Characteristics  of  a  Process. 


The  description  of  each  process  should  include  a  representation  of  the  flow  of  work  tasks 
as  well  as  the  artifacts  the  process  must  employ  and  produce,  as  shown  in  Figure  2. 
Figure  2  represents  an  expansion  of  the  “Tasks”  and  "Verijy  and  Validate"  blocks 
shown  in  Figure  1.  Note  that  in  Figure  2  the  task  network  illustrates  task  precedence. 
One  of  the  key  dimensions  of  the  representation  of  task  work  flow  is  the  capture  of  task 
precedence  constraints.  For  example,  all  of  the  links  shown  in  the  “Task  Work  Flow” 
portion  of  Figure  2  illustrate  finish-to-start  links,  where  one  task  must  finish  before 
another  may  begin.  Other  task  precedence  constraints  may  be  represented,  such  as  start- 
to-start,  finish-to-finish  and  start-to-finish  links.  These  links  describe  constraints  on  the 
flow  of  tasks  within  a  process  that  must  be  understood  to  enable  a  process  to  aid  in  the 
coordination  of  work  between  project  participants. 

Figure  2  also  illustrates  the  flow  of  artifacts  required  by  the  process,  so  that  developers 
undestand  the  artifact  derivation  chain.  It  provides  an  alternate  view  of  the  process  that 
supports  the  validation  of  tlie  planned  work  flow.  Process  engineers  can  use  the  artifact 
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flow  representation  to  ensure  that  the  planned  woric  flow  employs  and  produces  all  of  the 
artifacts  specified  in  the  artifact  flow.  Once  defined,  the  artifact  flow  can  be  integrated 
with  the  tasks  required  to  employ  and  prepare  the  specified  artifacts. 


Task 

Work  FLOW 


Task 

Artifact 

Flow 


toPerfomi  PerforniS  Criteria  (DID  I  Customer- 

Resources  DO  IT  RIGHT)  Critena(DtD 

Required  I  DO  THE 

RIGHT  THING) 


Effort  to  produce 


Am  fad 

Purpose, 

Form. 

Contents. 

and 

Derivation 


Figure  2;  Process  Work  and  Verification A^aUdation  Task  Dimensions.  Table  1 
provides  a  legend  for  the  letters  used  in  Figure  2. 


L=LoggiDg  task 

Task  specifies  data  logging  requirements. 

M=Measurement  task 

Task  specifies  a  required  measurement  to  post  or  compute  a  specific 
metric. 

T=Work  task 

Task  specifies  work  to  be  performed.  Bound  to  each  task  are: 
methods  to  support  the  task,  effort  to  perform  the  task,  agents  and 
resources  required  to  support  the  task. 

VA^=Verification  /  Validation 
task 

Task  specifies  verification  and  validation  work  to  be  performed. 

R=Reporting  task 

Task  specifies  status  and  event  reporting  requirements. 

N=Navigation  rules 

Rules  specify  process  navigation  conditions,  given  die  success  or 
failure  of  a  process  component's  verification  and  validation  tasks. 

A=Artifacts 

Bound  to  each  artifact  are:  effort  to  produce  and  die  artifacf  s 
description  (purpose,  form,  content,  derivation). 

Table  1:  Legend  for  Figure  2. 


Figure  2  also  illustrates  key  characteristics  that  work  flow  elements  must  address.  Note 
that  bound  to  each  task  is  a  method  which  prescribes  how  technical  work  will  be 
perfonned,  the  expected  effort  required  to  perform  the  task,  the  agents  identified  to 
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perform  it,  and  resources  identified  to  perform  it.  Also  note  that  bound  to  the  verification 
and  validation  tasks  are  pointers  to  specific  verification  and  validation  criteria.  For  more 
information  on  the  use  of  defined  process  components  to  prepare  project  processes, 
please  refer  to  the  paper  entitled  "Building  QuaUty  into  Process  Definitions  [Ett-95]." 

This  paper  describes  how  the  process  for  a  project  can  be  assembled  from  tailoring 
existing  and  defining  new  process  components.  We  shall  ask  the  reader  to  accept  that 
process  components  can  be  used  to  compose  larger  process  components,  and  ultimately  to 
compose  the  process  to  support  a  software  project. 

Table  2  provides  a  summary  of  the  characteristics  a  process  component  must  possess  to 
effectively  support  project  and  acquisition  planning  activities  [Ett-93]. 


Work  tasks 

Every  process  component  must  contain  a 
network  representation  of  aU  necessary 
project  tasks  and  their  constraints. 

Verification  and  vahdation  tasks 

Every  process  component  must  contain 
the  verification  and  validation  tasks 
necessary  to  support  the  evaluation  of 
work  results  produced  by  the  process 
component.  It  also  must  contain  pointers 
to  the  quality  criteria  to  be  used  to  support 
verification  and  vahdation  tasks. 

Effort  estimate 

Every  task  within  a  process  component 
must  identify  the  effort  required  to  support 
it. 

Resource  identification 

Every  task  within  a  process  component 
must  contain  a  pointer  to  the  personnel 
and  infrastructure  resources  necesstuy  to 
support  it. 

Artifact  identification 

Every  artifact  to  be  consumed  or  produced 
by  the  process  component  must  be 
identified,  and  further,  effort  to  produce 
artifacts  of  a  similar  class  should  be 
recorded. 

Measurement  tasks 

Tasks  may  be  included  in  process 
components  to  identify  where 
measurements  should  be  collected  or 
metrics  computed. 

Table  2:  Characteristics  of  the  Leveragable  Defined  Process 
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Status  reporting  tasks 

Tasks  may  be  included  in  process 
components  to  identify  when  and  what 
status  data  should  be  reported. 

Logging  tasks 

Tasks  may  be  included  in  process 
components  to  identify  when  and  what 
data  should  be  recorded  to  support 
historical  process  analysis. 

Navigation  rules 

Tasks  must  be  included  in  every  process 
component  to  identify  how  to  navigate 
within  a  project  process,  given  a  process 
component's  success  or  failure. 

Table  2  (Continued):  Characteristics  of  the  Leveragable  Defined  Process 


Section  2  -  Leveraging  Defined  Processes 

The  thesis  of  this  paper  is  that  defined  processes  should  be  the  starting  place  for 
supportmg  the  planning,  estimating  and  acquisition  of  a  software  system.  TTie  project 
plan  that  results  from  using  the  defined  project  process  becomes  the  vehicle  for  ensuring 
that  the  software  project  is  conducted  on  a  process-guided  basis,  from  the  standpoint  of 
both  monitoring  and  controlling  the  project,  and  ensuring  product  quality.  Further,  when 
events  occur  that  cause  the  project  to  replan,  the  process  is  a  tool  that  can  be  leveraged  to 
understand  how  to  recover  from  those  project  events.  Figure  3  illustrates  the  project 
planning  and  performance  activities  that  can  be  leveraged  from  a  defined  process  and  a 
process-driven  project  plan.  In  this  section,  we  shall  provide  an  overview  of  how  the 
project  plan  and  the  process  definition  from  which  it  was  derived  can  be  leveraged  by  the 
activities  identified  in  Figure  3. 
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Figure  3:  Activities  that  can  be  leveraged  from  the  project  process  and  the 
process-driven  project  plan. 


2.1  Leveraging  Defined  Processes  to  Plan,  Re-Plan  and  Estimate 
Software  Projects 

Planning  the  Software  Project  from  a  Defined  Project  Process 

After  the  project  process  has  been  defined,  it  can  be  used  to  derive  a  project  plan.  This 
project  plan  is  represented  as  a  network  of  activities  derived  from  the  process,  with  effort 
and  schedule  information  added.  This  scheduled  activity  network  can  be  analyzed  for 
reaUsm  with  respect  to  project  schedule  and  resource  limitations.  Using  a  process 
management  tool  such  as  PEAKS,  a  project  plan  can  easily  be  generated  from  a  defined 
project  process.  As  described  earlier  we  can  view  a  project  process  as  an  organized  and 
integrated  set  of  process  components,  which  describe  how  a  project  intends  to  produce  a 
set  of  work  results.  Each  process  component  can  be  viewed  as  a  generic  description  of 
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how  a  project  activity  will  be  performed  to  produce  a  specific  set  of  products.  For 
example,  to  produce  a  software  release  for  a  project,  the  process  may  require  the  creation 
of  release  specifications,  release  software  designs,  the  release  software,  and  a  release 
certification  report.  Given  that  the  project  identified  that  a  system  is  to  comprise  three 
releases,  a  process  could  be  instantiated  for  this  project  to  create  those  release  products 
for  each  specified  release.  In  this  way,  we  can  generate  a  plan  for  a  project  from  a 
defined  process. 

To  illustrate  how  a  process  definition  could  be  used  to  prepare  a  project  plan,  we  shall 
show  an  example  prepared  from  PEAKS  [Ett-92].  Figures  4,  5,  and  6  illustrate  the  use  of 
the  PEAKS  process  management  tool  to  generate  a  project  plan  from  a  defined  process. 
We  refer  to  this  as  process-driven  project  planning.  Figme  4  illustrates  a  process 
component  for  developing  softv'are  releases.  Ihis  process  component  requires  three 
inputs,  namely  1)  "REQ  DEV  SW  REL  (request  the  development  of  a  software 
release),"  2)  a  "Validated  SAS  (Software  Architecture  Skeleton),"  and  3)  a  "Validated 
System  Specification."  This  process  component  consists  of  two  work  tasks,  namely 
"Plan  SW  Release  (Plan  Software  Release)"  and  "Develop  Release  Software,"  After 
the  release  software  is  prepared,  it  is  certified  ("Certify  SW  Release"),  which  yields  the 
product  "Certified  Software  Release."  If  the  certified  software  release  passes  the 
"Appraise  Software  Release"  task,  the  final  product  of  the  process  component  is 
prepared,  namely  the  "Accepted  Software  Release."  Figure  5  illustrates  a  simple  project 
model  for  the  "SCAI"  project,  which  identifies  the  software  system  "SCAI"  being 
composed  of  two  releases,  namely  "CatMaint  (Catalog  Maintenance)"  and  "Surv  Proc 
(Surveillance  Processing)." 

Figure  6  illustrates  the  results  from  instautiating  process  component  "Develop  Software 
Release,"  where  the  process  component  activity  threads  are  duphcated  for  each  software 
release.  One  thread  is  generated  for  Catalog  Maintenance,  and  one  thread  is  generated  for 
Surveillance  Processing.  Also  note  in  Figure  6  that  the  "Validated  SAS"  and  the 
"Validated  System  Specification"  are  system  level  artifacts  produced  by  system  level 
processes.  The  requests  for  developing  software  releases  are  release  level  artifacts  and 
are  so  indicated  in  the  plan  activity  network.  After  a  project  process  definition  is 
instantiated  with  a  "project  model"  of  the  software  products  to  be  produced,  an 
unscheduled  activity  network  is  generated. 

From  this  discussion,  we  can  see  how  a  process  definition  could  be  leveraged  to  generate 
an  activity  network  for  use  in  supporting  the  project  planning  activities  of  scheduling  and 
estimating  the  cost  of  a  project  plan. 
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Figure  4:  Process  Component  for  ’’Develop  Software  Release' 
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Figure  5:  The  project  model  that  illustrates  the  products  that  must  be  produced  by 
the  ”SCAI  project  plan." 
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Figure  6:  An  instantiated  process  component  that  is  part  of  the  "SCAI  Project 
Process.” 


Scheduling  the  Generated  Project  Plan 

The  unscheduled  plan  generated  from  a  process  management  system  such  as  PEAKS 
should  be  scheduled,  based  on  the  estimated:  1)  effort  required  to  produce  each  required 
software  product,  2)  schedule  to  produce  each  product,  and  3)  resources  required  to 
produce  and  support  the  development  and  preparation  of  the  products.  PEAKS  permits 
the  project  planner  either  to  enter  this  data  in  PEAKS  for  plan  scheduling  or  to  export  the 
unscheduled  project  plan  to  a  project  management  system,  such  as  MicroPlanner  XPert^ 
or  CAT  Compass^.  Once  the  project  plan  is  scheduled,  the  plan  may  be  analyzed  from 
both  a  plan  and  process  perspective. 


^MicroPlanner  XPert  is  a  product  of  MicroPlanning,  International  of  Mountain  View,  California. 
^CAT  Compass  is  a  product  of  Robbins-Gioia  of  Alexandria,  Virginia. 
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Preparing  Data  to  Support  Cost  Estimation 

Using  a  process  management  system  such  as  PEAKS,  the  work  tasks  in  a  process 
component  can  be  directly  mapped  to  cost  model  phases  and  activities.  Given  this 
mapping,  when  effort  data  is  applied  to  the  work  tasks  of  a  process  component,  this  same 
effort  may  be  applied  and  accumulated  to  the  associated  cost  model  phases  and  activities 
of  a  selected  cost  model,  such  as  COCOMO  or  an  Activity  Based  Costing  model.  As 
shown  in  Figure  7,  the  effort  applied  to  the  work  tasks  of  process  component  X  are 
mapped  to  tlie  cost  model  phase  "DESIGN"  and  the  design  activities  "Definition"  and 
"Validation." 


Figure  7;  The  allocation  of  a  product  estimate  across  a  process  component's  tasks 
and  the  mapping  of  that  effort  to  cost  model  phases  and  activities. 

The  process  definer/project  planner  should  specify  1 )  the  effort  required  to  support  the 
work  tasks  of  a  process  component,  2)  the  resources  necessary  for  the  duration  of  the 
task,  and  3)  the  rate  of  application  for  each  resource.  The  role  resources,  e.g.  personnel, 
hardware,  software,  and  materials,  serve  as  the  basis  for  the  effort  estimates  of  a  cost 
model  and  may  be  exported  for  use  by  the  selected  cost  model  along  with  the  estimated 
effort  data.  Figure  8  illustrates  a  PEAKS  task,  and  identifies  "Cost  Model"  and 
"Resource  Model"  editors  for  identifying  the  cost  weights  for  the  task  of  a  process 
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Figure  8:  PEAKS  Task  Description  Editor,  illustrating  the  push  buttons  for  entering 
Cost  Model  and  Resource  Model  data. 

Thus,  as  we  have  discussed,  the  effort  and  schedule  data  applied  to  both  the  process 
components  of  a  process  model  and  the  tasks  of  an  unscheduled  plan,  may  be  leveraged 
to  define  inputs  to  support  project  cost  estimation,  once  the  project  plan  has  been 
scheduled. 
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component  and  the  resources  required  to  support  it.  Figures  9  and  10  illustrate  the 
PEAKS  Cost  Model  and  Resource  Editors  from  which  cost  model  and  resource 
information  may  be  entered. 


Figure  9:  Peaks  Cost  Model  Editor 


Figure  10:  PEAKS  Resource  Editor. 
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Validating  the  Project  Plan  for  Schedule  Realism 

After  the  project  plan  has  been  scheduled,  the  process  information  associated  with  the  plan 
representation  may  be  leveraged  to  support  project  plan  analysis  for  schedule  realism. 

Many  project  plans  are  prepared  as  "success  plans."  By  this  we  mean  that  the  plans  are  not 
robust  enough  to  tolerate  unforeseen  problems.  Many  managers  place  a  ten  to  fifteen 
percent  "management  reserve"  to  address  such  problems.  However,  by  using  the  process¬ 
generated  project  plan  as  a  mechanism  to  add  robustness  to  the  project  plan,  the  plan  can 
be  made  more  realistic  by  examining  the  process  and  identifying  areas  where  problems 
might  be  expected  due  to  the  unprecedented  nature  of  the  system  being  developed, 
unfamiliarity  with  the  application  domain,  or  the  introduction  of  new  technologies  and 
techniques  to  support  the  development  of  a  proposed  system. 

Supporting  project  plan  analysis  begins  with  process  definition.  Using  a  process 
management  tool  such  as  PEAKS,  process  definers  and  project  planners  may  instrument 
the  verification  and  validation  work  tasks  of  a  process  component  to  define  the  evaluation 
characteristics  that  must  be  examined  for  a  given  product  or  set  of  products  [Terr-92, 
Kras-92].  These  evaluation  characteristics  permit  project  personnel  to  determine  if  the 
products  they  have  produced  will  pass  verification  and  validation  work  tasks.  An  example 
of  instrumenting  a  validation  task  with  evaluation  criteria  is  shown  in  Figures  11,  12,  and 
13.  Figure  1 1  illustrates  the  selection  of  a  measurement  (or  evaluation)  framework  to 
support  the  validation  task  and  the  data  collection  form  selected  from  that  fi'amework. 
Figure  1 1  also  includes  a  field  labeled  "Branch."  This  field  is  used  to  specify  pointers  to 
activities  in  the  activity  network  in  which  to  branch,  upon  a  verification  or  validation  task 
failure.  This  feature  supports  rewoik  analysis.  Figures  12  and  13  illustrate  the  selection  of 
the  measurement  framework  and  the  selection  of  the  appropriate  data  collection  forms. 

The  pass/fail  aspect  of  verification  and  validation  activities  provides  project  planners  with 
the  ability  to  "breakpoint"  a  project  plan,  much  like  a  programmer  would  "breakpoint"  a 
program.  By  "breakpointing"  a  program,  the  programmer  can  analyze  the  state  variables  of 
a  program  and  interim  program  results.  Similarly,  by  "breakpointing"  a  project  plan, 
project  planners  can  analyze  what  the  effects  are  on  a  plan,  given  a  verification  or 
validation  woric  task  failure,  and  the  rework  required  to  address  the  failure.  In  this  way, 
project  plan  scenarios  can  be  prepared  to  indicate  plan  problems  and  the  rework  required 
to  address  them.  The  rework  requirements  may  be  factored  into  building  in  pre  planned 
rework  cycles  into  the  project  plan,  making  the  plan  more  robust.  Thus,  we  have  shown 
how  the  project  plan  and  the  process  from  which  it  was  created  can  be  leveraged  to 
support  the  analysis  of  project  plans  for  their  schedule  realism  and  how  they  could  be  made 
more  robust. 
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Figure  11:  An  example  PEAKS  validation  work  task  editor.  This  figure  illustrates  1) 
the  measurement  fi'amewoik  and  the  associated  data  collection  form  selected  to  support  the 
validation  task,  and  2)  the  branching  condition  (or  navigation  rule)  in  the  process  definition, 
given  the  validation  criteria  are  not  satisfied. 
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Figure  12:  Illustrates  the  selection  of  the  measurement  (or  evaluation  criteria)  to 
support  the  validation  of  a  work  product  or  result 


Figure  13:  This  flgure  illustrates  the  menu  from  which  the  process  definer  would 
select  the  appropriate  data  collection  form  to  support  the  associated  validation  work 
task. 
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Re-planning  the  Software  Project  from  a  Defined  Project  Process 

One  of  the  requirements  we  identified  for  defining  a  process  was  the  specification  of 
navigation  rules.  Figure  1 1  illustrated  where  a  branching  condition  could  be  specified 
that  identified  where  the  process  would  need  to  branch  within  the  activity  network  to 
address  a  verification  or  validation  work  task  failure.  Using  a  process  management  tool 
such  as  PEAKS,  multiple  branching  conditions  may  be  specified  in  the  verification  and 
validation  work  tasks.  When  the  project  plan  is  declared  operational  and  the  project 
begins  to  provide  status  information  against  this  plan,  PEAKS  will  address  verification 
and  vahdation  work  task  failures,  based  on  the  failure  occurrence.  The  first  occurrence  of 
a  verification  or  vahdation  task  failure  will  activate  the  first  branching  condition.  The 
second  occurrence  will  activate  the  second  branchiug  condition,  etc.  Thus,  a  process 
definer  could  decide  that  the  first  and  second  verification  and  validation  failures  will  be 
handled  as  an  internal  rework  cycle  of  a  particular  process.  The  process  definer  could 
also  decide  to  branch  to  a  management  task  for  task  problem  review  if  a  third  verification 
or  vahdation  failure  occurs.  Because  the  process  management  system  maintains  a 
complete  network  of  all  activities  and  knowledge  of  the  rework  required  to  address 
verification  and  vahdation  failures,  the  system  should  be  capable  of  producing  new 
project  plans,  addressing  the  portions  of  the  project  plan  that  require  rework  and  the 
portions  that  still  have  not  been  performed.  Thus,  we  have  shown  how  the  project  plan 
and  the  process  from  which  it  was  created  can  be  leveraged  to  support  project  replanning. 


2.2  Leveraging  Defined  Processes  and  Process-Driven  Project  Plans  to 
Support  Software  Systems  Acquisition 

One  of  the  chief  concerns  of  the  government  and  industry  is  performing  the  necessary 
groundwork  to  support  die  acquisition  of  a  software  intensive  system  or  a  system  in 
which  software  is  a  major  part.  Cost  modeling  tools  and  project  management  systems 
have  been  tools  used  to  support  system  acquisihon  planning.  Acquisition  planners  need 
to  examine  ah  facets  of  the  life-cycle  cost  for  a  proposed  system,  from  its  up-ffont 
planning  and  procurement  to  system  deployment  and  maintenance.  With  an 
understanding  of  the  software  and  management  processes  required  to  plan,  develop,  field, 
and  maintain  a  complex  software  system,  acquisition  planners  can  gain  a  better 
understanding  of  the  effort  and  costs  required  to  acquire  and  maintain  a  projxtsed 
software  system. 

As  shown  in  Figure  14,  a  process  management  tool  such  as  PEAKS  could  be  used  to 
provide  the  information  necessary  to  support  1)  the  preparation  of  a  baseline  cost 
estimate,  2)  project-activity-based  costing,  and  3)  the  generation  of  project  management 
reports  useful  in  supporting  acquisition  planners.  The  Government  currently  maintains 
historical  data  on  the  cost  of  the  acquisition  of  systems,  and  inflation  factors  to  support 
the  estimation  of  the  cost  of  a  system’s  procurement  in  current  dollars.  Similarly,  the 
government  could  build  up  an  historical  repository  of  project  plans  and  the  processes 
from  which  they  were  generated  to  prepare  a  project  plan  for  a  proposed  system 
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acquisition.  Given  that  data  was  recorded  to  capture  the  costs  associated  with  each 
process  component  of  the  project  process,  this  data  could  be  leveraged  to  support  project 
cost  estimation.  Further,  where  product  quality  requirements  and  the  activities  necessary 
to  support  them  were  associated  with  components  of  the  project  process,  the  acquisition 
plannner  could  make  appropriate  adjustments  to  both  the  quaUty  requirements  and  the 
costs  necessary  to  support  product  verification  and  vahdation,  thus  ensuring  more 
accurate  projected  project  plans  and  cost  estimation  data.  As  mentioned  previously, 
PEAKS  could  then  be  employed  to  analyze  the  project  plan  for  realism,  given  proposed 
schedule  and  cost  factors.  Further,  plans  could  be  examined  for  the  affects  of  potential 
rework,  using  historical  data  and  the  precedented  or  unprecedented  nature  of  the  system 
to  be  developed,  as  well  as  the  acquisition  planner's  understanding  of  the  complexity  of 
the  application  domain. 

By  supporting  system  acquisition  plarming  with  a  tool  such  as  PEAKS,  plaimers  could  1) 
better  understand  the  activities  required  to  develop  a  proposed  system,  2)  better 
understand  the  cost  of  quality  for  the  proposed  system,  and  3)  be  in  a  better  position  to 
estimate  the  costs  of  a  plarmed  procurement  from  the  costs  allocated  to  the  products  a 
process  must  create,  the  effort  required  to  perform  each  process  component  of  a  project 
plan,  and  the  process  component's  associated  tasks. 


Figure  14:  PEAKS  Support  for  Software  Systems  Acquisition  Planning 
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2.3  Leveraging  Process-Driven  Project  Plans  to  Support  Software 
Projects 

Once  the  project  plan  has  been  accepted,  and  the  project  begins  to  follow  the  plan,  the 
process  management  system  can  provide  varying  levels  of  support  depending  on  the  - 
software  engineering  environment  provided  to  support  project  work.  There  are  two 
potential  scenarios  we  shall  briefly  discuss: 

1)  The  process  management  system  as  a  stand-alone  system 

2)  The  process  management  system  integrated  with  a  process  enactment  system. 


The  Process  Management  System  as  a  Stand-Alone  System 

Where  the  process  management  system  is  employed  as  a  stand-alone  system,  its 
capabilities  as  a  project  management  system  could  be  exploited  or  it  could  be  configured 
to  work  with  an  external  project  management  system.  To  receive  the  full  benefits  from 
tlie  system,  plan  activity  status  must  be  provided  to  the  process  management  system. 

This  will  enable  it  to  identify  what  work  has  been  performed,  what  work  is  currently 
scheduled,  and  the  products  and  resources  required  to  support  that  work. 

The  process  management  system's  facilities  should  also  be  employed  to  support  product 
verification  and  validation  review  tasks.  A  process  management  tool  such  as  PEAKS 
provides  project  management  capabilities  and  also  provides  a  measurement  quality  facility 
that  can  be  invoked  as  a  stand-alone  tool  to  support  product  and  work  result  verification 
and  validation  tasks.  If  this  facility  is  employed,  PEAKS  may  be  used  to  effectively 
support  project  replanning.  Given  that  PEAKS  is  updated  on  a  routine  basis,  it  will 
provide  project  management  with  an  effective  capability  to  monitor  and  control  the 
software  project  -  on  a  process  basis. 


The  Process  Management  System  Integrated  with  a  Process  Enactment 
System 

The  basic  difference  between  the  use  of  a  process  management  tool  such  as  PEAKS  as  a 
stand-alone  capability  and  its  use  with  a  process  enactment  system  is  its  ability  to  have 
the  status  and  event  data  it  requires  automatically  reported  by  a  specially  prepared  set  of 
programs  which  assist  project  personnel  in  following  the  process  defined  using  the 
process  management  tool.  We  refer  to  these  programs  as  "process  programs."  Where 
process  programs  are  instrumented  to  report  status  data,  project  events  and  employ  tools 
to  support  verification  and  vaUdation  tasks,  such  as  the  PEAKS  measurement  quality 
facihty  (MQF),  this  data  can  automatically  be  reported  to  PEAKS.  This  permits  project 
management  to  employ  PEAKS  as  a  system  to  support  project  monitoring  and  control, 
and  decision  support,  where  data  about  the  project  is  automatically  collected  and  made 
available  for  report  generation  and  project  status  review.  Where  data  is  automatically 
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reported  to  PEAKS,  "condition  watchers"  may  be  set  up  to  examine  the  PEAKS  database 
and  new  transactions  for  unusual  conditions.  When  the  "condition  watchers"  identify  an 
anomaly,  they  can  report  it  to  management  for  action  in  a  timely  manner.  Examples  of 
watchers  that  might  be  set  up  are  to  identify  schedule  anomalies,  such  as  a  task  that  has 
passed  its  late  start  window,  or  cost  anomalies,  such  as  the  identification  of  "earned 
value"  problems. 


Section  3  -  STARS  Experiences  and  Conclusions 

One  of  the  goals  of  the  STARS  program  was  to  produce  a  process  management  system 
that  supported  the  concepts  of  process-driven  project  planning  and  process-driven 
software  development  and  management.  Another  of  the  project's  goals  was  to  provide  an 
infrastructure  in  which  to  pull  together  activities  and  data  used  to  support  project  planning 
and  project  management.  In  this  way  we  could  more  closely  tie  the  disciplines  of  process 
definition,  project  plarming,  project  cost  estimation,  and  project  monitoring  and  control. 
Our  work  on  STARS  with  PEAKS  and  its  forerunner  SPMS  (Software  Process 
Management  System)  indicates  that  we  are  heading  in  a  positive  direction  to  achieve  tliese 
goals. 

We  wrote  this  paper  to  provide  the  reader  with  some  examples  of  how  the  process 
definition  prepared  for  a  project  could  be  leveraged  to  support  a  number  of  important 
project  planning,  acquisition,  and  performance  activities.  To  date  we  have  practical  field 
experience  in  process  definition  and  process-driven  project  planning.  We  have  positioned 
ourselves  on  the  STARS  program,  through  the  efforts  of  the  Loral  STARS  Team  and 
Cedar  Creek  Process  Engineering,  to  test  all  the  concepts  described  in  this  paper  on  future 
projects  at  the  U.S.  Army’s  Picatiimy  Arsenal  and  on  the  Air  Force/STARS 
Demonstration  Project  (SCAJ  Project)  in  Colorado  Springs,  Colorado.  Our  plans  are  to 
do  just  that,  as  well  as  to  transition  our  process  management  concepts  and  technology  into 
business  units  of  Loral  Federal  Systems. 

From  our  work  we  have  concluded  that  process-driven  project  planning  can  and  does 
work  and  can  become  a  driving  force  in  the  planning  of  projects  that  wish  to  employ  the 
concepts  of  megaprograming.  Further,  we  have  concluded  that  "quahty"  must  be  built 
into  our  process  definitions,  along  with  the  activities  required  to  support  it,  so  that  those 
activities  will  appear  in  our  project  plans,  and  thus  ensure  that  both  government  and 
contractor  persoimel  imderstand:  1 )  the  process  by  which  a  product  will  be  created;  2) 
the  evaluation  characteristics  by  which  those  products  will  be  assessed;  and  3)  the  project 
plan  that  addresses  how  the  above  will  be  satisfied.  Our  ultimate  hoi>e  is  that 
organizations  will  recognize  that  the  project  plan  and  the  process  definition  from  which  it 
was  derived  can  be  leveraged  to  develop  quahty  software  within  a  plan  that  aU  parties 
understand  and  beheve. 
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